Dockerise testing for dev #1093
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Scott-Simmons
force-pushed
the
dockerise-testing-for-dev
branch
2 times, most recently
from
469f111
to
6773ae4
Compare
Add image for testing tsfresh with multiple python versions. This can be a good final sanity check e.g. before a release.
Targets include 1. Building dockerised testing environment 2. Testing tsfresh within testing environment 3. Testing tsfresh locally with tox with available python versions 4. Testing tsfresh locally with current active python version 5. Cleaning build artifacts 6. Formatting. This is so that changes can be made before pushing the changes up the remote to trigger the formatting checks. TODO: pre-commit hooks should probs be added too.
Change docs to reflect the new testing invokations.
Scott-Simmons
force-pushed
the
dockerise-testing-for-dev
branch
from
6773ae4
to
27f02b9
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related: #994.
Easiest to go commit by commit. Uses 3 "flows"
(1) Test locally on specific python version Is useful for quick iteration.
(2) Test locally on the discoverable python versions Is a useful sanity check for ensuring new development works on multiple versions of python.
(3) Test in dedicated testing environment with guaranteed availability of python versions Is a good final sanity check. Takes longer, but creates a reproducible environment to test off and is a good 'source of truth'.
1 Test locally on specific python version
Testing time for one version is ~1 min. Note this includes the speedup from cached packages
2 Test locally on the discoverable python versions
Testing time across versions 3.7-3.11 is ~4 mins, but note that this speedup includes the speedup from cached packages.
Also note that python 3.7 fails on my machine due to some idiosyncratic issue related to my setup
py37/lib/python3.7/site-packages/pip/_vendor/typing_extensions.py... getting same error as here but not using vscode. Not an issue for me personally but shows an example of why testing within an isolated testing environment could be a good way to ensure reproducible version targeting.3 Test in dedicated testing environment with guaranteed availability of python versions
Build time for testenv ~5 mins but this is a once-off build for the testenv.
Testing time across versions 3.7-->3.11 is ~6 mins.